Typical computing devices may rely on software agents, such as anti-malware agents, for security. However, it is difficult to keep up with the increasing number of malware attacks on users' devices. To combat the malware threat, there is a trend to protect security sensitive software by running it inside a Trusted Execution Environment (TEE). TEEs provide a sterile environment that can protect secrets even when other parts of the system are compromised. Examples of TEEs include Intel® Software Guard Extensions (Intel® SGX), secure virtual machines (VMs), and a converged security engine (CSE). The TEE, while useful to protect secrets within the TEE, may not protect I/O data such as user and sensor data that is communicated into and/or out of the secure “container.” The security requirements for trusted I/O vary per use case and device, and involve flavors and combinations of confidentiality, integrity, liveliness, and replay protection.
Current processors may provide support for a trusted execution environment such as a secure enclave. Secure enclaves include segments of memory (including code and/or data) protected by the processor from unauthorized access including unauthorized reads and writes. In particular, certain processors may include Intel® Software Guard Extensions (SGX) to provide secure enclave support. In particular, SGX provides confidentiality, integrity, and replay-protection to the secure enclave data while the data is resident in the platform memory. The on-chip boundary forms a natural security boundary, where data and code may be stored in plaintext and assumed to be secure. Intel® SGX does not protect I/O data that moves across the on-chip boundary.
Trusted applications that process I/O data often require assurance that the data they consume (or produce) originated from a specific source device (for input) or will reach a specific device destination device (for output). Trusted applications may also need assurance that the integrity of the data in transit, between the application and the device, is preserved and that an adversary cannot replay data that was captured earlier. Integrity violations must be detectable by the trusted application (for input) or the consuming device (for output). For example, a banking application may require that the keyboard input from the user for a fund transfer transaction be integrity protected. Without integrity protection, malware on the platform could modify the user-entered transfer amount in memory before it is processed by the application, causing a different transaction to be executed than what the user intended.
There are known cryptographic algorithms to calculate an integrity measure over data, such as message authentication codes (MACs). Existing I/O controllers and software stacks (e.g., bus drivers, device drivers, etc.) do not carry this extra information in addition to the data. Additionally, many existing hardware devices and controllers do not support cryptographic primitives for generating the metadata required to validate integrity and authenticity.
Video capture controllers typically organize captured video data as circular queues of frame buffers. Video acceleration controllers typically organize captured data as pipelines of frame buffers. Frame buffer data is typically accessed by video capture and acceleration controllers in fixed-sized units, which are typically cachelines. Video acceleration hardware may access frame buffer data linearly (e.g., as sequential pixels), as tiles (e.g., arrays of pixels), or randomly.